@rflechtner I am not understanding what I am doing wrong. I have inconsistent results running yarn install and yarn build on my machine and in the CI.

Check your node version. Also, check what version of Yarn you are running compared to the package.json

@rflechtner after changing the dependency type from peer dependency back to regular dependency, everything seems to be building ok and tests seem to pass (minor what was already broken on develop). I would then ask you to provide your feedback, or if you think the dependency should be a peer dependency, to try to fix it yourself as I honestly have no clue.

@rflechtner after changing the dependency type from peer dependency back to regular dependency, everything seems to be building ok and tests seem to pass (minor what was already broken on develop). I would then ask you to provide your feedback, or if you think the dependency should be a peer dependency, to try to fix it yourself as I honestly have no clue.

Peer dependencies have no effect besides issuing warnings in the CLI, so my guess the dependency was not actually being installed. I'm fine with leaving it as a regular dependency, given that it's from an entirely different stack of dependencies than the @polkadot/api related code. On this note though, is there no support from the @polkadot/api suite for checking the metadata hash? I'm not sure it's a great idea to start mixing the pjs and papi toolchains.

@rflechtner gotcha 👌

As for the library, unfortunately pjs itself does not offer the feature. The available options are the ones listed in this Polkadot Forum. Even the Polkadot Apps code relies on the @polkadot/api library for this one feature: https://github.com/polkadot-js/apps/blob/f63da86b9a29bc9a99aaa18c75db61c242b9d9fd/packages/react-signer/src/signers/LedgerSigner.ts#L15.

Anyway, in order to test this, we first must fix an issue with our build pipeline that is failing to push new Docker images on DockerHub (just found out). @ggera is on it. Once that's resolved, I will try to push an empty commit to re-trigger the tests, and see if everything works fine. This should also fix the broken pipeline currently on develop, since the fixes for the missing runtime APIs have not been picked up cause there was no image pushed.

@rflechtner gotcha 👌

As for the library, unfortunately pjs itself does not offer the feature. The available options are the ones listed in this Polkadot Forum. Even the Polkadot Apps code relies on the @polkadot/api library for this one feature: https://github.com/polkadot-js/apps/blob/f63da86b9a29bc9a99aaa18c75db61c242b9d9fd/packages/react-signer/src/signers/LedgerSigner.ts#L15.

I see! https://www.npmjs.com/package/merkleized-metadata seems lighter on additional dependencies, but choose whichever you think gets the job done.

Once that's resolved, I will try to push an empty commit to re-trigger the tests, and see if everything works fine.

You can also just hit the 'Re-run jobs' button on the actions status page (https://github.com/KILTprotocol/sdk-js/actions/runs/12633893068?pr=924)

@rflechtner The only concern with this package it doesn't seem maintained. I offered this yesterday but I think we should find another package if possible that is maintained or stick with Papi.

I think re-running the same job does not pull the latest version of a Docker image, does it? I think I tried this once, but sure I will try first to re-run the job once the new images are available.

@rflechtner The only concern with this package it doesn't seem maintained. I offered this yesterday but I think we should find another package if possible that is maintained or stick with Papi.

+1 on this. I think we should stick with papi.

@rflechtner resetting to develop and re-installing dependencies still changes all hashes. So I force-pushed changes to the files and package.json, but not yarn.lock. Would you be able to fix that, and then I could go ahead with writing some integration tests for it?

After spending a lot of time on this and not understanding why tests would pass when using Chopsticks but not when using the standalone-node binary, I came across this notice that says that the metadata check extension does not work with native runtimes. At the moment, we still use the NativeElseWasmExecutor for both our binaries, which means this feature is untestable until we switch to a pure WasmExecutor. Actually, the feature is unusable in general until we switch to the WasmExecutor, but until this PR is merged, nothing breaks as the default behaviour is to ignore the metadata hash.

@rflechtner the CI is still broken due to missing runtime API decorations, but you can verify the changes work by running the new Blockchain integration tests locally.